今天我們要介紹的工具是記憶體面版中的最後一個工具: Record Allocation Profiler，這個工具可以讓我們按函數來檢視說那些函數佔用了許多記憶體，也可以讓我們直接追回原始碼。

我們今天使用的範例是昨天的程式碼，你可以在 Codepen.io 上找到這個範例

在開始前我們一樣先打開 Chrome 開發者工具然後切換到記憶體面版 (Memory panel)，再選用我們今天要使用的工具 Record Allocation Profiler，最後再按下 Start 按鈕。這時候它就會開始錄制記憶體的使用狀況，現在點擊頁面上的 Create memory leaks 按鈕幾次，然後再用工具列上的停止錄制按鈕或是中間的 Stop 按鈕來停止錄制。在停止錄制後你就會得到一份報告，它也會出現在左邊的列表中。這份報告會類似下圖：

圖 1 : 我們得到的報告

• Self Size: 函數本身執行所需用的記憶體
• Total Size: 函數執行完所需用的所有記憶體(包含對其他函數的呼叫)
• Function: 執行的函數

這邊你可以使記憶體使用量的排序，它預設是把使用量最大的排在上面 (按 Self Size)，不過我們要看的是實際執行完所需要的記憶體，所以我們要看 Total Size，你可以在 Total Size 上點二下讓它重新排序，這時候我們可以看到使用最大量的記憶體函數中有一個 grow ，也就是我們程式中自訂的函數。它後面也有列出函數原始碼的所在位置，點擊後它就會帶你到原始碼面版去。這邊很有趣的一件事是我們可以看到其他幾個使用最大量的函數都是來自原生的陣列 native array.js ，因為我們在這個 grow 函數裡有用到這些函數，所以它也出現在這列表中。

圖 2 : 從圖表中我們可以看到 grow 函數

這個介面也提供了視覺化的圖表，你可以用上方的下拉選單來切換到 Chart，裡面就可以很明顯看到從 grow 函數一直呼叫到 SparseJoinWithSeparatorJS 這個函數，我猜這個函數應該就是最底層的函數。

圖 3 : 視覺化圖表

小結

今天我們把記憶體工具的所有功能都看完了，有了這幾個工具我相信你已經可以針對你的網頁來做記憶體檢測，找出你的頁面是否有記憶體洩漏，是不是有什麼函數用掉很多的記憶體。而就像我們前面講的，記憶體檢視算是比較困難的除錯，我們應該稱它叫做調校 (Performance tuning)，以前端來說是比較少被重視的主題(以我自己的了解)。但其實現在因著單頁式應用程式 (Single Page Application) 成為前端的主流，我們的頁面不再一直刷新 (每次頁面刷新，JavaScript 就會重新載入，所以記憶體會被釋放) 當程式有記憶體洩漏或其他記憶體的問題時，就會影響整個使用者經驗。我相信在不久的未來這個主題也會變成前端重視的區塊之一。

也建議大家可以再多試幾個會造成記憶體洩漏的範例，讓自己對這工具更加熟悉。明天我們要很快的用效能面版 (Performance panel) 來檢測記憶體洩漏。